Lightwell et SAP : quand les correctifs ne suffisent pas à eux seuls

L'open source est désormais indissociable des applications d'entreprise modernes. Cela vaut également pour les environnements SAP, même si le logiciel utilisé ne représente qu'une partie de l'ensemble de la pile technologique. En effet, ces systèmes s’accompagnent de plateformes d’intégration, de développements internes, de solutions d’automatisation, d’interfaces, d’outils de surveillance et de nombreuses autres applications, dont beaucoup reposent sur des composants open source ou en intègrent en tant que dépendances. Il en résulte une chaîne logistique logicielle nettement plus vaste que le produit SAP proprement dit.

Pour la sécurité informatique, il s'agit d'un problème majeur que les processus classiques de gestion des vulnérabilités ne résolvent que partiellement. Un scanner détecte une version vulnérable et le fabricant ou la communauté open source met à disposition une version corrigée. Techniquement, la faille serait ainsi corrigée, mais sur le plan opérationnel, l'affaire est loin d'être réglée. En effet, la nouvelle version n'est pas nécessairement compatible avec les systèmes existants.

Une mise à niveau peut modifier les API, remplacer des dépendances transitives, provoquer des régressions ou nécessiter une nouvelle certification. Dans le cas d’une application critique pour l’entreprise, il est donc important non seulement de savoir si un correctif est disponible, mais aussi comment l’intégrer à la version existante du logiciel. Comme de nombreuses entreprises redoutent ce risque ou ne souhaitent pas le prendre, les vulnérabilités connues restent donc sans solution, s’accumulent sous forme d’exceptions de sécurité à long terme ou nécessitent des correctifs propriétaires coûteux et des branches (forks).

Ce moment mythique nous oblige à repenser notre façon de voir les choses

Cette évolution s'accélère considérablement avec l'intelligence artificielle. Dans le cadre du projet Glasswing d'Anthropic, le modèle Mythos Preview a permis de détecter des milliers de failles de sécurité dans des logiciels open source, dont près de 3 900 failles de gravité élevée ou critique. L’IA est capable d’analyser du code à une vitesse impossible à atteindre avec les méthodes manuelles traditionnelles. Cela modifie également la dynamique des failles « zero-day » : plus les surfaces d’attaque potentielles sont identifiées rapidement, plus la fenêtre temporelle pour les corriger se referme vite. Pour une entreprise prise isolément, il est pratiquement impossible d’évaluer et de hiérarchiser elle-même chaque vulnérabilité détectée. Cela aggrave à son tour le problème du « remediation gap ». Des semaines, voire des mois, peuvent s’écouler entre la découverte d’une faille de sécurité et sa correction effective dans une application en production. Pendant ce temps, les entreprises se retrouvent soit avec une faille connue, soit obligées de gérer leurs propres correctifs, soit confrontées à la décision de procéder à une mise à niveau risquée.

Mais les „ anciennes “ vulnérabilités restent également un problème. Log4Shell en est un exemple particulièrement frappant. Cette faille de sécurité dans la bibliothèque Java Apache Log4j, très répandue, a été rendue publique fin 2021 et classée comme critique. Les applications utilisant une version vulnérable et non mise à jour de cette bibliothèque ont été touchées. Dans certaines conditions, des pirates pouvaient l’exploiter pour exécuter à distance du code malveillant et obtenir ainsi un accès étendu aux systèmes concernés. Même si Log4Shell est généralement corrigé sur les systèmes importants, les dépendances Log4Shell obsolètes – et donc oubliées – dans la chaîne d’approvisionnement logicielle continuent de présenter d’énormes vulnérabilités.

À cela s'ajoute le fait qu'une mise à jour de sécurité mise à disposition ne suffit pas à elle seule. Le chemin menant du correctif à la mise en production est souvent semé d'embûches : l'application doit être recompilée, des tests automatisés et manuels doivent être effectués, les dépendances doivent être vérifiées et les modifications doivent être validées. Pour les applications critiques, il faut parfois compter en plus des validations techniques, des exigences de conformité ou des processus de changement formels. La rapidité des processus en aval devient donc un facteur essentiel. Une entreprise peut avoir accès à une nouvelle mise à jour de sécurité aussi rapidement qu’elle le souhaite : si le processus interne de compilation et de déploiement prend plusieurs semaines, voire plusieurs mois, la vulnérabilité persiste pendant tout ce temps, voire n’est tout simplement pas traitée.

Lightwell : correctif de sécurité au lieu d'un changement de version imposé

C'est précisément cette lacune que comble Lightwell, une initiative conjointe de Red Hat et d'IBM visant à sécuriser la chaîne d'approvisionnement des logiciels open source. Ce concept s'appuie sur un principe que Red Hat applique depuis des décennies dans le domaine des logiciels d'entreprise : les correctifs de sécurité ne sont pas nécessairement fournis via un saut de version complet, mais peuvent être rétroportés de manière ciblée vers une version toujours prise en charge. L'objectif est d'intégrer la modification liée à la sécurité sans imposer pour autant un changement inutile au niveau des fonctionnalités ou de l'API. Pour les entreprises, c'est un aspect important : un backport corrige la faille de sécurité sans modifier automatiquement l'ensemble de la structure des dépendances de l'application.

La différence par rapport à un fork manuel est ici énorme. Une entreprise pourrait certes, en théorie, copier le code source d’une bibliothèque concernée, appliquer le correctif et créer son propre artefact. Mais cela impliquerait également d’assumer de manière permanente la responsabilité de cette fourche : processus de compilation, signature, dépendances, correctifs de sécurité supplémentaires, documentation et, le cas échéant, réintégration ultérieure dans le code en amont. Une autre différence par rapport à la gestion traditionnelle des correctifs réside dans ce qui se passe après l’application de la mise à jour. Dans une chaîne logistique logicielle moderne, il ne suffit plus de mettre à disposition un nouveau fichier JAR. Les entreprises doivent pouvoir retracer ce qu’elles utilisent, d’où cela provient, comment cela a été construit et quelles informations de sécurité y sont associées.

Lightwell fournit donc non seulement des artefacts corrigés et signés, mais aussi des métadonnées relatives à la chaîne d'approvisionnement. Celles-ci comprennent notamment les nomenclatures logicielles (SBOM), la provenance SLSA de niveau 3 ainsi que les signatures via Sigstore ou Cosign. Cela revêt une importance particulière pour les clients SAP, car, comme indiqué précédemment, la dépendance à l’open source ne s’arrête pas aux limites du système SAP. Dans un environnement d’intégration, les bibliothèques Java, les composants de messagerie, les API, les conteneurs, les outils de build ou les frameworks d’IA peuvent faire partie du système global. Une SBOM rend ces composants visibles sous une forme lisible par machine. VEX (Vulnerability Exploitability Exchange) va même encore plus loin.

Une SBOM répond essentiellement à la question de savoir quels composants sont présents. VEX peut fournir des informations complémentaires permettant de déterminer si et dans quelle mesure un logiciel est réellement affecté par une vulnérabilité donnée. Pour les entreprises soumises à une réglementation, cela revêt une importance cruciale. Les exigences issues de la DORA, de la directive NIS2 ou de la loi sur la cyber-résilience (Cyber Resilience Act) renforcent la pression pour documenter de manière traçable les composants logiciels, les vulnérabilités et leur traitement. Lightwell met à disposition ces informations avec les artefacts, ce qui évite de devoir les rassembler manuellement a posteriori à partir de différentes sources.

Ces éléments vérifiables relatifs à la chaîne d'approvisionnement et à la construction sont également pertinents au regard des futures exigences européennes en matière de certification et de conformité, ou de celles à caractère volontaire, telles que l'EUCS (European Cybersecurity Certification Scheme for Cloud Services) ou l'EUCC (European Common Criteria-based Cybersecurity Certification Scheme).

Deux versions adaptées à différents besoins

De plus, Lightwell ne se limite pas au correctif final. Ce modèle combine un tri assisté par l’IA à l’expertise humaine en ingénierie. L’IA aide à gérer le flux massif de CVE en analysant les vulnérabilités en quelques secondes, en évaluant leur pertinence et en proposant des correctifs possibles. Les modifications qui en résultent sont ensuite testées de manière automatisée et validées par des experts humains – plus précisément par plus de 20 000 techniciens de Red Hat et d’IBM – avant d’être mises à disposition sous forme d’artefacts. Les correctifs développés ne sont pas seulement mis à la disposition des clients, mais sont également restitués aux projets d’origine, dans l’esprit de la communauté open source, afin que l’ensemble du secteur puisse en bénéficier.

Dans un premier temps, l'écosystème Lightwell se concentre sur Maven/Java. Cela présente un intérêt particulier pour les clients SAP, car les applications Java s'approvisionnent souvent en dépendances via des référentiels Maven et jouent un rôle dans de nombreux scénarios d'intégration, de middleware et d'applications propres aux clients. Dans le même temps, Java n’est qu’un début. Lightwell doit être étendu à d’autres écosystèmes tels que PyPI, npm et Go afin de répondre aux exigences des secteurs réglementés, dans lesquels la gestion des versions fixes ou « pinées » revêt une importance particulière. La solution est actuellement disponible en deux versions différentes.

Lightwell Network offre un accès en libre-service au catalogue disponible de paquets adaptés et corrigés. Cela inclut des fichiers binaires et du code source signés numériquement, ainsi que des artefacts de conformité. Lightwell Clearinghouse Premier, quant à lui, s'adresse aux secteurs fortement réglementés qui nécessitent un accompagnement intensif. Les entreprises bénéficient en outre, entre autres, d’une notification des vulnérabilités pour les versions de paquets spécifiques au client, d’une vérification prioritaire des nouvelles vulnérabilités, ainsi que d’un responsable de compte technique (TAM) dédié à la sécurité et d’une correction garantie par contrat (basée sur un SLA) pour certains domaines d’application.

Qu'est-ce que cela signifie concrètement pour les clients et les partenaires SAP ?

Il est important que les clients SAP sachent que Lightwell n’est pas destiné à remplacer les mises à jour de sécurité régulières. Si une vulnérabilité est détectée dans un produit SAP, la responsabilité de sa correction incombe en principe à SAP. Les correctifs correspondants sont fournis via les processus établis, tels que les notes de sécurité SAP. De plus, Lightwell ne remplace pas les processus de sécurité et de développement existants au sein des entreprises. Cela inclut, d’une part, les outils de scan des vulnérabilités ; d’autre part, la responsabilité de l’intégration, des tests d’application, de la validation et du déploiement incombe toujours à l’entreprise. Lightwell modifie toutefois le point de départ technique de ces tests. La dépendance utilisée en production conserve dans un premier temps sa version existante, tandis que le correctif de sécurité est rétroporté de manière ciblée vers cette version. L’artefact est signé, accompagné d’informations sur la chaîne d’approvisionnement et peut être obtenu via le processus existant de référentiel et de compilation. Au lieu de valider un saut de version complet, c’est donc un correctif de sécurité ciblé qui est validé.

Lightwell devient ainsi également intéressant pour les partenaires SAP. Les intégrateurs de systèmes, les cabinets de conseil et les prestataires de services gérés peuvent ainsi enrichir leurs compétences existantes en matière d’exploitation SAP, de gestion du cycle de vie des applications, de gestion du changement et de DevSecOps. Les partenaires peuvent, par exemple, commencer par apporter de la transparence sur les dépendances open source d’un environnement applicatif. Ils peuvent ensuite évaluer quels composants sont particulièrement critiques, quelles failles de sécurité existent déjà et à quel stade, entre la disponibilité des correctifs et la mise en production, des retards surviennent. Une autre piste réside dans l’intégration aux processus DevSecOps existants. Les artefacts Lightwell doivent être intégrés dans les référentiels, les processus de compilation et les procédures de test. Les recompilations et les tests automatisés peuvent contribuer à réduire le délai entre la mise à disposition d’un correctif et sa mise en production. Pour les prestataires SAP, il ne s’agit pas d’une discipline totalement nouvelle, car ils disposent d’une expérience suffisante en matière de gestion des versions, de copies de systèmes, de processus de transport et d’exploitation de systèmes critiques pour l’entreprise. Ces compétences peuvent désormais être transposées aux dépendances open source liées aux applications SAP. Les questions de gouvernance et de conformité en font également partie. Les entreprises ont besoin d’informations traçables et surtout vérifiables concernant les composants utilisés, les vulnérabilités existantes, les correctifs appliqués et le moment où ceux-ci ont été mis en production.

L'open source a besoin d'un processus de maintenance solide

La véritable importance de Lightwell ne réside pas dans un référentiel ou un correctif isolé. Il s'agit plutôt de s'attaquer à un problème structurel de la chaîne d'approvisionnement open source. L'open source accélère l'innovation, mais répartit la responsabilité des différents composants au sein d'un écosystème complexe. Les entreprises doivent néanmoins traiter ces composants comme faisant partie intégrante de leur propre chaîne d’approvisionnement. Cependant, avec les progrès de l’IA et l’accélération de l’analyse des vulnérabilités qui en découle, il devient de plus en plus difficile de corriger chaque vulnérabilité détectée via un processus de mise à jour classique.

C'est là qu'intervient Lightwell, avec sa combinaison de triage assisté par IA, de génération automatisée de correctifs, de rétroportage vers des versions de production concrètes, de validation technique, de distribution signée et d'artefacts de conformité lisibles par machine. L'objectif est de mettre en œuvre les processus de sécurité en production de manière contrôlée et traçable, même lorsqu'un saut de version n'est pas une option viable pour des raisons techniques, réglementaires ou opérationnelles.

Vers l'inscription du partenaire :